home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1996 #15
/
Monster Media Number 15 (Monster Media)(July 1996).ISO
/
netmail
/
netg4p.zip
/
NETMGR.DOC
< prev
next >
Wrap
Text File
|
1996-05-26
|
89KB
|
2,529 lines
===================================================================
NetMgr - "The Swiss Army Knife for Netmail"
Copy, move, delete, file, change and bounce netmail..
(c) 1992,93,94,95,96 Gerard van Essen (2:281/527)
===================================================================
! NetMgr uses the Squish MSGAPI by Scott Dudley.
! Squish is a trademark of Scott J. Dudley
! JAM(mbp) - Copyright 1993 Joaquim Homrighausen, Andrew Milner,
Mats Birch, Mats Wallin.
ALL RIGHTS RESERVED.
NetMgr version : 1.00.g4
Last update of this document : may 26, 1996
Throughout the documentation, you will see items that are marked with a
'plus' sign, like this: {+}.
This indicated that the described feature is only available for
registered users of NetMgr.
┌──────────────┬─────────────────────────────────────────────────
│ Introduction │
└──────────────┘
NetMgr is a program that will scan the messages in one or more NETMAIL
area(s), and analyse the headers of those messages. The messages can be
stored in *.MSG, Hudson, Squish or JAM format.
NetMgr only scans NETMAIL areas, _not_ echomail areas. You can try to run
NetMgr on echomail areas, but unpredictable things can (and will) happen,
so don't do it!
NetMgr will check if any of the headers meet the criteria specified in the
configuration file (a 'mask'), created by the user. If any of those
headers are found, NetMgr can perform several actions on that message,
like moving or copying it to another message area, deleting it, changing
it etc.
┌─────────────────────────────────────┬─────────────────────────────
│ Copyright, license and disclaimer.. │
└─────────────────────────────────────┘
* "NetMgr" refers to the executables and documentation in the
original distribution archive. NetMgr is copyrighted material by
Gerard van Essen. It may only be used in agreement with the
conditions set out in this license agreement.
* You are entitled and encouraged to copy and distribute NetMgr,
provided you do not change the contents of the NetMgr archive or
the program itself, and no money or any other compensation is
asked or accepted for NetMgr (without written permission from the
author).
Distribution of modified or incomplete archives is prohibited.
* Although care has been taken to write and test a program that
does what this document states, the program is provided as is,
without warranty or guarantee of any kind, either expressed or
implied, as to the quality or performance of this program,
except that it will occupy disk space.
* The author, Gerard van Essen, will not be held liable to you or
anyone for (but not limited to) any direct, indirect, incidental
or consequential damages, including any lost profits, lost
savings which may result from the use or inability to use this
program.
Gerard van Essen is in no way obligated to provide future
versions of, or support for this software.
Your use of the program constitutes your agreement to this
license and disclaimer and your release of the author from any
form of liability or litigation.
* COMMERCIAL use of the program: you are a commercial user if you
make a profit from running NetMgr, or if you use NetMgr in a
commercial environment (i.e.. business, governmental organization,
association, school, foundation, or any other form of juridical
person). In case of doubt, contact the author.
* For NON-COMMERCIAL use, it is REQUIRED that you register the
program.
However, if you really cannot afford to register (mainly a concern
to 'eastern block' countries, the former USSR etc.), permission is
hereby granted to use an unregistered version.
Remember, if you register, you are paying for something that you
already have! Registration does not mean you can force me to
implement new features that you like.
* For COMMERCIAL use of the program, you should always register
the program. You are, however, granted an evaluation period of
30 days. After these 30 days, you must either register the
program, or stop using it. Using an unregistered version of
NetMgr in a commercial environment for more than 30 days is
prohibited!
* You only have to register once. Your registration will also be
valid for all future releases of NetMgr.
* Registration is valid for all versions of NetMgr. At this moment,
there are DOS and OS/2 versions of the program available.
Registering NetMgr entitles you to run the DOS version, the OS/2
version, or both :-)
* A registration is PERSONAL. It cannot be transferred to other
parties. It could, however, be used in different places (but: by
the same PERSON). Think of it as a book in this regard: you can
take the book from your home to the office (and read it there).
* Versions of NetMgr prior to version beta 0.97 were freeware and could
not be registered. You may continue to use THESE OLDER VERSIONS
without registration, even in a commercial environment.
* The author reserves the right to change this license without
prior notice, for newer versions of the program.
┌────────────────────────────────────┬─────────────────────────────
│ A 'MASK', NetMgr's driving force.. │
└────────────────────────────────────┘
As mentioned in the short introduction, NetMgr will scan the headers of
all messages in a netmail area to see if a header meets the criteria that
are set by the user in NetMgr's configuration file. These criteria are
specified in a 'mask'.
A 'mask' consists of six parts:
fromname, fromaddress, toname, toaddress, subject, attributes
(1) (2) (3) (4) (5) (6)
So 6 parts, separated by a comma. In the config file you use the keyword
MASK to specify a mask:
MASK fromname, fromaddress, toname, toaddress, subject, attributes
NAME : fromname, toname
───────────────────────
A 'name' is just a string, leading and trailing spaces found in the config
file are stripped, spaces *within* a string are allowed.
So writing " Gerard van Essen " will be the same as "Gerard van Essen".
(Note that leading and trailing spaces are stripped, while the space
between "Gerard" and "van" is still there...)
NetMgr will do a compare that is NOT case sensitive. In other words:
as far as NetMgr is concerned, "GERARD van ESSEN" is the same as "gerard
VAN essen" and the same as "GeRaRd VaN eSsEn".
A name can start with a tilde (~). This indicates that you are not looking
for an exact match of the string, but that you are looking for a
substring. As long as the string you specify is located somewhere in the
name, it will be a match.
So, if you specify '~essen' as a name, it will be a match if the name is
'Gerard van Essen', and also if it is 'Art van Essen' etc.
A name can also start with an exclamation mark (!). This indicates that you
are looking for a string that does NOT match what you specify. So if you
specify '!Gerard van Essen', NetMgr will work on messages where the string
is NOT 'Gerard van Essen'.
You can also combine the '~' and '!' tokens. The '!' MUST be always the
first token if you do that!
For example: !~essen will look for string that do NOT contain 'essen'
anywhere in the string. In that case 'Gerard van Essen' will not be a
match, 'Art van Essen' will not be a match, but 'Nick Wirth' will be a
match.
SUBJECT
───────
A subject is just a string, exactly like a 'name'. Everything that applies
to a 'name' also applies to a 'subject'. See the paragraph above..
ADDRESS: fromaddress, toaddress
───────────────────────────────
An address is *always* full 4D (4 dimensions: zone, net, node, point),
write a '*' for any part you don't care about:
60:*/*.* - all messages coming from zone 60
2:281/527.* - msg from any point from 281/527, or .0
*:500/*.* - all messages from nodes/points in a net 500, any zone
2:281/527.0 - only messages from 2:281/527.0
Just one exception (to the "always 4D" rule): specifying just a '*' only
for the address is allowed (strictly speaking, it is not full 4D :-), and
is the same as *:*/*.*.
An address can also start with an exclamation mark. That indicates that you
are looking for messages where the address does NOT match what you are
specifying here.
For example: !2:*/*.* will let NetMgr work on all addresses that are NOT
zone 2. And !2:281/527.0 will let NetMgr work on all addresses that are NOT
2:281/527.
ATTRIBUTES
──────────
Attributes can be one or more of the following:
p = private
c = crash
r = received
s = sent
a = attach
i = forward/intransit
o = orphan
k = kill
l = local
h = hold
f = file request
n = scaNned
d = Direct
u = Update request
q = return receipt reQuest
y = return receipt
m = iMmediate
t = TFS
e = KFS (erase)
z = Archive sent
2 = XX2, officially unused/reserved
b = is return receipt
g = confirm receipt request
$ = message is locked
% = JAM, zonegate bit
x = message is a FAX cover
Special attributes to support nodelist lookups of node numbers:
@ = Check destination address.
# = Check origination address.
These two special attributes will be explained later.
■ Important note:
Several of these extra attributes can only be represented in the '^AFLAGS'
kludge (that is NOT supported by Squish, but is by Frontdoor and several
other programs), in some message base formats (like *.MSG and Squish).
If you do NOT want to use this FLAGS kludge (because you use Squish in a
Binkley environment), you can put the keyword 'NOFLAGS' in your config.
This gives you the ability to use 'direct' (in the peculiar way that Squish
supports it).
You can NOT use: IMM, TFS, KFS or Archive Sent in this ('NOFLAGS') mode for
Squish and *.MSG areas!
NetMgr will NOT write out a FLAGS kludge in this ('NOFLAGS') mode, so
rewriting a message that has these FLAGS will make these FLAGS disappear!!
The JAM message base format supports ALL attributes without any kludges.
Every attribute must have a '+' or a '-' in front of it.
A '+' means: must be present.
A '-' means: must *not* be present.
An example:
+l+p
A message only matches this, if the L)ocal bit, and the P)rivate bits are
set. The other (possible) attributes are not important.
-f+l
A message matches this, if it is *not* a F)ile request, and the L)ocal bit
is present.
+c+l+p-s
A message matches this, if the C)rash bit is set, the L)ocal bit is set
and the P)rivate bit is set. Apart the that, the message must *not* be
S)ent already..
The special nodelist 'attributes'.
----------------------------------
NetMgr also supports two special attributes that can check whether a
certain address is in the nodelist or not.
The following two tokens represent these special attributes:
@ = Check destination address.
# = Check origination address.
Just like the other attributes, a '+' or a '-' must be used in front of
these attributes:
+@ means the destination address must be listed.
-@ means the destination address must NOT be listed.
+# means the origination address must be listed.
-# means the origination address must NOT be listed.
* Note: if the message originates from, or is destined for a point
address, NetMgr will try to locate the Boss of this point in the
nodelist. If the Boss is listed, the point address is also assumed to be
listed.
Checking whether or not a node is in the nodelist can be quite useful.
Sending out a message to a node that is unlisted is bound to fail, so it
may be useful to bounce such a message, or at least give a warning about
this situation.
Similarly, if you receive a message FROM a node that is unlisted, you may
be warned that returning a reply to that address may fail because of this
situation.
The special nodelist attributes can be simply combined with other
attributes:
+l+p-@
A message matches these attributes, if the L)ocal bit, and the P)rivate
bits are set. Additionally, the message must be addressed to a node that
is not listed in the nodelist.
+p-@-#
A message matches these attributes, if the P)rivate bit is set, the
message is addressed to a node that is not listed in the nodelist, and the
message originates from a node that is not listed either.
-@+#
A message matches these attributes, if it originates from a listed node,
but is addressed to an unlisted node.
In order to use these special attributes, you must also specify what type
of nodelist you use, and where it is located. NetMgr supports the Version
7 nodelist (used by for example Binkley), the FrontDoor nodelist (used by
FrontDoor and Intermail) and the GIGO nodelist (a compiler to generate a
GIGO nodelist is supplied with NetMgr). The keywords that can be used to
specify the nodelist are presented later in this document.
Some examples of a complete 'MASK'.
───────────────────────────────────
Mask Gerard van Essen, *, *, *, *, +s
All messages, coming from "Gerard van Essen" on any address (*), written
TO: anyone (*) on any address (*), with any subject, that are already
flagged as S)ent.
IE: all messages written by me that have already been packed/sent.
--
Mask *, 2:281/527.*, uucp, 2:281/527.0, *, +l-h-p-k
Message written by anyone (any name: '*'), on node 2:281/527 (.* so it can
be the NODE 2:281/527 or any of its points, like 2:281/527.40).
Written TO: a guy named "UUCP" on node 2:281/527.
The L)ocal bit must be set, and the H)old, P)rivate and K)ill bits must
*not* be set.
The subject doesn't matter.
--
Mask *, 2:281/527.*, postmaster, 2:281/527.0, *, *
Message written by anyone (any name: '*'), on node 2:281/527 (.* so it can
be the NODE 2:281/527 or any of its points, like 2:281/527.40).
Written TO: a guy named "Postmaster" on node 2:281/527.
The subject and message attributes that are (not) present are not
important.
--
Mask *, *, raid, 2:281/527.0, *, *
All messages, coming from anyone on any address, but addressed to RAID on
2:281/527. The subject & message attributes don't matter.
--
Mask *, *, ~essen, 2:281/527.0, ~timed, *
All messages, addressed to a name that contains the string 'essen', on
node 2:281/527, that have the string 'timed' somewhere in the subject.
--
Mask ~gerard, !2:281/527.0, *, *, *, *
All messages, coming from someone whose name contains 'gerard', but whose
address is NOT 2:281/527.
So it will be from someone with a nice name, but it won't be from me :-)
--
Mask *, *, !~essen, 2:281/527.0, *, *
All messages with node 2:281/527 as their destination, but not addressed
to anyone who has the string 'essen' in his/her name.
So messages addressed to my system, but not for me personally (most likely
a message for one of my BBS users).
--
Mask *, !2:281/527.0, *, *, *, -@-l
All messages that are not originating from node 2:281/527, have a
destination address that is unlisted in the nodelist and do not have the
'local' bit present.
--
Mask *, *, *, *, *, -#
Any message that originates from an unlisted system.
NetMgr also offers another type of Masks: eXtended Masks (XMASKs), with
much more capabilities than standard masks. These will be explained
later in this document.
First we will take a look at what NetMgr can actually do when it find a
message that matches a certain mask.
┌────────────────────────┬─────────────────────────────────────────────
│ MASK's partner: ACTION │
└────────────────────────┘
A MASK is never alone, it is always accompanied by one or more ACTION
statements. This ACTION statement tells NetMgr what should be done with
messages that match a certain MASK.
In the ACTIONs mentioned below, <destination area> can be any for the
following formats:
*.MSG : give the path of the *.MSG area (c:\fd\rcvd\).
Squish : give the path + basename of this area, and put a '$' in front of
it, to indicate Squish format ($c:\squish\netmail).
JAM : give the path + basename of this area, and put a '!' in front of
it, to indicate JAM format (!c:\fe\msgs\saved).
Hudson : give the board number of this area, and put a '#' in front of
it, to indicate Hudson format (#102).
The following ACTIONs are valid:
■ COPY <destination area>
──────────────────────────
Copy a message to another area. This HAS TO BE a netmail area. It can be a
*.MSG, JAM, Squish or Hudson area (see above). The original message will
be left alone, NetMgr will simply make a copy.
An example:
Action Copy c:\fd\netmail
This will copy a message to the *.MSG area c:\fd\netmail (there is no
leading '#', '$' or '!' so it is a *.MSG area.
Action Copy #13
This will copy a message to a Hudson area (because of the leading '#')
with board number 13.
■ MOVE <destination area>
──────────────────────────
Move a message to another area. This HAS TO BE a netmail area. It can be a
*.MSG, JAM, Squish or Hudson area (see above). The original message will
be deleted after a copy is placed in the destination area.
An example:
Action Move !e:\msgbases\artware
This will move a message to the JAM style area (because of the leading
'!') e:\msgbases\artware.
■ DELETE
────────
Delete a message. This action has no parameters. The message will be
deleted.
■ DELETEATTACH
──────────────
This action will not only delete the message, but it will also look at
any attached files. When the 'Truncate when sent' flag is present on
the message, the file(s) will be truncated. When the 'Kill file when
sent' flag is present, the attached file(s) will be deleted.
■ FILE <output text file>
──────────────────────────
Write the message to a text file. NetMgr will write out the message (header
+ body) to a plain (ASCII) text file. The original message will be left
alone. The body of the message will be formatted with a right margin of
80.
If the file does not exist, it will be created. If it exists already, the
message will be appended at the end of the file.
Example:
Action FILE d:\output\msgtext.txt
This will add the message to the textfile d:\output\msgtext.txt.
■ HDRFILE <output text file>
─────────────────────────────
Write message header to a textfile. NetMgr will write out the message
(header only) to a plain (ASCII) text file. The original message will be
left alone.
If the file does not exist, it will be created. If it exists already, the
message will be appended at the end of the file.
Example:
Action FILE d:\output\msgtext.txt
This will add the header of message to the textfile d:\output\msgtext.txt.
■ SEMAPHORE <path+filename>
───────────────────────────
Generate/touch a semaphore. A semaphore is a 0 byte file, that is often
used as a simple way to communicate between different programs. Different
courses of action can be taken based on the existence of a semaphore.
This can be easily accomplished in batch files, by using the 'if exist ..'
and 'if not exist' commands.
If the semaphore file does not exist, it will be created. If it already
exists, it will be 'touched': the date and time of the file will be set to
the current date and time.
■ REWRITE <mask>
─────────────────
Rewrite (change) the header.
This action takes a full 'mask' as parameter. A rewrite mask may contain
the wildcard token ('*') as well. All fields where a '*' is specified will
be left unchanged. This allows you to change only a certain field in the
header without changing any of the other fields.
Some examples:
Action Rewrite *, *, Gerard van Essen, *, *, *
This will change the TO: name in 'Gerard van Essen', but will not change
anything else in the header (or body, for that matter) of the message.
Only the contents of the TO: name field is changed.
Action Rewrite *, *, *, 2:281/527.0, *, *
This will change (only) the destination address of the message. It will be
set to 2:281/527.0. All other fields will be left unchanged.
Action Rewrite *, *, *, 2:*/*.*, *, *
This will change (only) zone of the destination address of the message. It
will be set to zone 2. The rest of the address is not changed. So a
message originally to 1:100/1.0 will be changed to 2:100/1.0, while a
message originally to 70:256/123.0 will be changed to 2:256/123.0.
All other fields will be left unchanged.
Action Rewrite *, 2:281/527.0, *, *, Interesting subject, *
This will change the origination address of the message. It will be set to
2:281/527.0. Additionally, the subject will be set to 'Interesting
subject'. The other fields will be left unchanged.
Action Rewrite *, *, *, *, Interesting subject, -c+h
This will set the subject to 'Interesting subject'. Additionally, the
'hold' attribute will be added to the message (+h) and the 'crash'
attribute will be stripped (-c).
The other fields will be left unchanged.
You can also use '@myaka' instead of 'address' as the origination
address. This will let NetMgr pick the most appropriate AKA
automatically. See the special section about AKAmatching later in the
documentation.
■ UUCPREWRITE <mask>
────────────────────
Rewrite header and add the contents of the 'TO: name' field to the body,
at the top of the message. This can be useful for Internet <-> FidoNet
gates.
UUCPrewrite works exactly like a 'normal' rewrite, but will also add the
TO: name to the body of the message.
An example:
Action UUCPrewrite *, *, uucp, 2:281/999.999, *, -c+l
A message like this:
From: Pietje Puk, 2:281/0
To : art@cnh.wlink.nl, 2:281/527
Subj: test
-------------
Hello!
.
.
Will be rewritten to:
From: Pietje Puk, 2:281/0
To : uucp, 2:281.999.999
Subj: test
--------------
TO: art@cnh.wlink.nl
Hello!
.
.
■ BOUNCE <address> <bounce text file>
──────────────────────────────────────
Return message to the sender, and add bounce text at the top.
This action returns a copy of the entire message, including the header
information.
The address used as origination address (in the origination address,
MSGID) is the first item you specify. As all addresses in Netmgr.cfg, this
needs to be a full 4D address. You *must* specify this item (it may not be
'*'), because NetMgr needs to know a valid origination address to use.
You can also use '@myaka' instead of 'address' as the origination
address. This will let NetMgr pick the most appropriate AKA
automatically. See the special section about AKAmatching later in the
documentation.
The original message is left untouched. If you want to send back the
message *and* get rid of the original message, you must first have an
'Action Bounce' and then an 'Action Delete' line for a certain mask.
Otherwise the original message will just stay there, and might trigger an
'Action Bounce' on the next run of NetMgr.
If the original message contains the REPLYTO/REPLYADDR kludges (as
specified in FSC-0035), NetMgr will properly bounce this message back to
the other network (most likely internet), with a correct TO: line at the
top of the message.
{+} You can use variables in the textfiles that can be inserted at the
top of the message.
These variables will be expanded using the contents of the
message header of the message you are bouncing. This gives you the
opportunity to make the messages a bit more 'personal'.
In the file, the use of the following variables is now allowed:
%to : The full name of the person that the the original message
was addressed to.
%fto : As %to, but only the first name of that person.
%from : The full name of the person who wrote the original
message.
%ffrom : As %from, but only the first name of that person.
%subj : Subject of the original message.
%orig : Address of the sender of the message (like 2:281/527)
%dest : Address of the recipient of the message (like 2:281/527)
%time : Time the message was written (like 01:25)
%year : The year the message was written (like 1993)
%mon : The month the message was written (like jan, feb etc)
%day : The day of the month msg was written (a number)
%dow : The 'day of week' msg was written (like mon, tue, wed etc)
So, the contents of the bounce file could be:
-=-
Hello %ffrom!
You sent a message to %to (%dest), dated %mon %day, %year. The subject
was: "%subj".
-=-
These variables can only be used by registered users of NetMgr.
■ EMPTYBOUNCE <address> <bounce text file>
───────────────────────────────────────────
Return message to the sender, add bounce text at the top.
This action returns nothing, apart from the 'bouncetext', there will be no
information in the message body.
The address used as origination address (in the origination address,
MSGID) is the first item you specify. As all addresses in Netmgr.cfg, this
needs to be a full 4D address. You *must* specify this item (it may not be
'*'), because NetMgr needs to know a valid origination address to use.
You can also use '@myaka' instead of 'address' as the origination
address. This will let NetMgr pick the most appropriate AKA
automatically. See the special section about AKAmatching later in the
documentation.
The original message is left untouched. If you want to send back the
message *and* get rid of the original message, you must first have an
'Action EmptyBounce' and then an 'Action Delete' line for a certain mask.
Otherwise the original message will just stay there, and might trigger an
'Action EmptyBounce' on the next run of NetMgr.
If the original message contains the REPLYTO/REPLYADDR kludges (as
specified in FSC-0035), NetMgr will properly bounce this message back to
the other network (most likely internet), with a correct TO: line at the
top of the message.
{+} You can use variables in the textfiles that can be inserted at the
top of the message. See the action 'bounce' for more information on
this.
■ HDRBOUNCE <address> <bounce text file>
─────────────────────────────────────────
Return message to the sender, add bounce text at the top.
This action returns the message header, in addition to the 'bouncetext'.
The body of the original message will not be sent back, however.
The address used as origination address (in the origination address,
MSGID) is the first item you specify. As all addresses in Netmgr.cfg, this
needs to be a full 4D address. You *must* specify this item (it may not be
'*'), because NetMgr needs to know a valid origination address to use.
You can also use '@myaka' instead of 'address' as the origination
address. This will let NetMgr pick the most appropriate AKA
automatically. See the special section about AKAmatching later in the
documentation.
The original message is left untouched. If you want to send back the
message *and* get rid of the original message, you must first have an
'Action HdrBounce' and then an 'Action Delete' line for a certain mask.
Otherwise the original message will just stay there, and might trigger an
'Action HdrBounce' on the next run of NetMgr.
If the original message contains the REPLYTO/REPLYADDR kludges (as
specified in FSC-0035), NetMgr will properly bounce this message back to
the other network (most likely internet), with a correct TO: line at the
top of the message.
{+} You can use variables in the textfiles that can be inserted at the
top of the message. See the action 'bounce' for more information on
this.
■ XBOUNCE {+}
■ XHDRBOUNCE {+}
■ XEMPTYBOUNCE {+}
──────────────────
The BOUNCE, HDRBOUNCE and EMPTYBOUNCE Actions have 'extended'
counterparts: XBOUNCE, XHDRBOUNCE and XEMPTYBOUNCE.
The format:
XBOUNCE <textfile for bouncetext> <full mask to use>
The first parameter is the textfile to add at the top of the bounce
message.
The second parameter is the mask to use for the bounce message. You can
specify a "*" for the fields where you want the default to be used.
By default, NetMgr generates a full 'reply header' with the to: and from:
names and addresses reversed (compared to the original message) and the
same attributes and subject.
For example, for this message:
From: Gerard, 1:1/1
To : SysOp, 1:138/211
Subj: Test!
Attr: Pvt Cra
----------------------------------
The standard reply header is:
From: SysOp, 1:138/211
To : Gerard, 1:1/1
Subj: Test!
Attr: Pvt Cra
----------------------------------
And that will be the result if you specify a mask like:
Action XBounce c:\txt\bounce.txt *, *, *, *, *, *
However, if you make it:
Action XBounce c:\txt\bounce.txt The Bodyguard, 2:281/527.0, *, *, *, +l
The result would be:
From: The Bodyguard, 2:281/527
To : Gerard, 1:1/1
Subj: Test!
Attr: Loc
----------------------------------
{+} You can use variables in the textfiles that can be inserted at the
top of the message. See the action 'bounce' for more information on
this.
The extended bounce actions are only available to registered users.
■ ADDNOTE <textfile>
────────────────────
This will add the text from <textfile> at the top of the message. You
could use this to send a message through with a note ('please do not
reply through this system, the originating system is unlisted').
The message is not changed in any other way.
■ FORWARD <mask>
────────────────
This action will forward the message (showing both header and body, like
'bounce' does) to someone else.
The header of the message will be constructed using the mask you specify.
However, the header (that is: from, to, subject, destination address,
origination address and attributes) will be initialized with the
contents of the original message.
Putting a '*' in fields of the masks will, as a result, produce the
contents of the header of the original message.
Example:
An example:
Action Forward *, *, Kasper Kwant, 2:500/144.0, *, +l+c
A message like this:
From: Gerard, 2:281/527
To : SysOp, 1:138/211
Subj: Test!
Attr: -
----------------------------------
Will produce a message like this:
From: Gerard, 2:281/527
To : Kasper Kwant, 2:500/144
Subj: Test!
Attr: Loc, Cra
----------------------------------
* Forwarded by NetMgr+ 1.00.g2
Original message:
From:
To : <--- header of original message.
Subj:
----------------
Bla, bla <--- body of original message.
You can also use '@myaka' instead of 'address' as the origination
address. This will let NetMgr pick the most appropriate AKA
automatically. See the special section about AKAmatching later in the
documentation.
■ MAKEMSG <file for body> <mask>
────────────────────────────────
This will generate a new message, using the Mask you specify as the
header, and the contents of a file you specify as the body.
However, the header (that is: from, to, subject, destination address,
origination address and attributes) will be initialized with the
contents of the original message.
Putting a '*' in fields of the masks will, as a result, produce the
contents of the header of the original message.
Example:
Action MakeMsg c:\body.txt Art, 2:281/527.0, SysOp, 1:138/211.0, Poll!, +l
This will generate a message to SysOp on 1:138/211, with body.txt as the
body of the message.
You can also use '@myaka' instead of 'address' as the origination
address. This will let NetMgr pick the most appropriate AKA
automatically. See the special section about AKAmatching later in the
documentation.
■ BOUNCEIN
■ HDRBOUNCEIN
■ EMPTYBOUNCEIN
■ XBOUNCEIN {+}
■ XHDRBOUNCEIN {+}
■ XEMPTYBOUNCEIN {+}
■ FORWARDIN
■ MAKEMSGIN
────────────────────
Several actions have a similar counterpart, that can place the resulting
message in another area.
The actions concerned are: the Bounce and XBounce 'family', Forward and
MakeMsg. In order to place the resulting message in another area, add
'IN' to the action name (to make BOUNCEIN, XBOUNCEIN, XEMPTYBOUNCEIN,
FORWARDIN etc), and add the path/name of the area to put the message in.
Some examples:
Action XBOUNCEIN $d:\msg\net bounce.txt The Bouncer, @myaka, *, *, *, +l
This will create a bounce message in the Squish area d:\msg\net.
Action FORWARDIN !c:\msgbase\netmail *, *, Pietje Puk, 2:2/2.0, *, +l
This will forward a message to 'Pietje Puk (2:2/0)' in the JAM style area
c:\msgbase\netmail.
■ CHANGEPATH <new path>
───────────────────────
This action replaces the path of files found in the subject line. It makes
sense to only use this for file attach messages, as you will get a
terribly messed up subject line otherwise :-)
Example:
Action ChangePath c:\frodo\infiles
In the above example, the subject line:
Subj: c:\tmp\myfile.txt d:\outfiles\test.txt
will be rewritten to:
Subj: c:\frodo\infiles\myfile.txt c:\frodo\infiles\test.txt
If a file does not have a path at all, the defined path will be added:
Subj: test.txt
will get:
Subj: c:\frodo\infiles\test.txt
If the defined change will lead to a subject line that is too long (the
new path is longer than the old one, and the subject would get longer than
71 chars) the message will not be changed.
Note that the actual file is left untouched. NetMgr only works on the
subject line of the message. No actual files are moved.
■ CHANGEPATHMOVE <new path>
───────────────────────────
This works exactly like 'ChangePath', but it also moves the attached
file(s) to the new directory.
■ ECHOCOPY <address> <area> <seenby>
────────────────────────────────────
Copy a netmail message to an echomail area. Add an origin and (optionally)
a SEEN-BY: line.
The address used as origination address (in the origin, MSGID) is the
first item( <address>). As all addresses in Netmgr.cfg, this needs to be a
full 4D address. You *must* specify an address here, because NetMgr needs
this information to generate a correct Origin line. Specifying a '*' is
not allowed.
Leave SEEN-BY: info out if you don't want it. The text put here is just
duplicated in the SEEN-BY line, so you can put more than one address here.
Take care what you specify: the text is simply copied verbatim. If you
specify an illegal address or format, NetMgr will simply copy it, making
the message invalid.
If the original message already contained a tear- or origin line, NetMgr
will strip it and replace it with a newly generated, correct tear/origin
line. This makes sure the correct address is used in the origin line and
that the message is a valid echomail message (with an origin line).
NetMgr also adds or replaces the MSGID with a newly generated, correct
(ie: using the correct address) MSGID.
The result of all this should be a valid, fresh echomail message, that has
the same header and body as the original message. The original message
will be left untouched.
An example:
Action EchoCopy 2:281/527.0 $c:\msgs\maillist
This will take a message and generate an echomail message out of it, using
2:281/527 as Origin address. The echomail message will be generated in the
Squish area (because of the leading '$' that denotes a Squish style area)
c:\msgs\maillist. No SEEN-BY will be added.
Action EchoCopy 2:281/527.0 !c:\msgs\maillist 281/528
This will take a message and generate an echomail message out of it, using
2:281/527 as Origin address. The echomail message will be generated in the
JAM area (because of the leading '!' that denotes a JAM style area)
c:\msgs\maillist. The string '281/528' will be added to the SEEN-BY.
Action EchoCopy 2:281/527.0 !c:\msgs\maillist 281/528 529
This will take a message and generate an echomail message out of it, using
2:281/527 as Origin address. The echomail message will be generated in the
JAM area (because of the leading '!' that denotes a JAM style area)
c:\msgs\maillist. The string '281/528 529' will be added to the SEEN-BY.
Action EchoCopy 2:281/527.0 #13 pietje puk
This will take a message and generate an echomail message out of it, using
2:281/527 as Origin address. The echomail message will be generated in the
Hudson board (because of the leading '#' that denotes a Hudson style area)
number 13. The string 'pietje puk' will be added to the SEEN-BY. This will
generate an invalid message and you will definitely be in trouble because
of this!
■ ECHOMOVE <address> <area> <seenby>
────────────────────────────────────
Move a netmail message to an echomail area and add an origin and
optionally a SEEN-BY.
The address used as origination address (in the origin, MSGID) is the
first item( <address>). As all addresses in Netmgr.cfg, this needs to be a
full 4D address. You *must* specify an address here, because NetMgr needs
this information to generate a correct Origin line. Specifying a '*' is
not allowed.
Leave SEEN-BY: info out if you don't want it. The text put here is just
duplicated in the SEEN-BY line, so you can put more than one address here.
Take care what you specify: the text is simply copied verbatim. If you
specify an illegal address or format, NetMgr will simply copy it, making
the message invalid.
If the original message already contained a tear- or origin line, NetMgr
will strip it and replace it with a newly generated, correct tear/origin
line. This makes sure the correct address is used in the origin line and
that the message is a valid echomail message (with an origin line).
NetMgr also adds or replaces the MSGID with a newly generated, correct
(ie: using the correct address) MSGID.
The result of all this should be a valid, fresh echomail message, that has
the same header and body as the original message. The original message in
the netmail area will be deleted.
■ IGNORE
────────
This action does absolutely nothing, but is it a 'match', so scanning for
a matching mask will stop after this.
For example:
Mask *, 2:281/527.0, *, *, *, *
Mask *, 2:281/528.0, *, *, *, *
Mask *, 2:281/529.0, *, *, *, *
Action Ignore
Mask *, *, *, *, *, *
Action Delete
This will make sure the 'delete' action is never reached for messages
originating from 281/527, 281/528 or 281/529.
■ PACKMAIL <origination address> <destination address> [<password>]
───────────────────────────────────────────────────────────────────
This action keyword activates NetMgr netmail packing capabilities. NetMgr
will take the message and place it in a mailpacket in a Binkley style
outbound area (these mailpackets are always called '*.?UT).
The mailpacket header will contain the addresses you specify here. So the
mailpacket will be from <origination address> to <destination address>.
Please note that this is only in the PACKET HEADER, not the individual
messages that are inside the packet. Those individual message (obviously)
have the origination and destination addresses that were present in the
message itself when it was found in your netmail area.
The origination address *must* always be a fully specified 4D address,
using '*' is not allowed (NetMgr needs an address to use as origination
address).
In the destination address, however, you are allowed to use '*'. The
destination address of the mailpacket will then be the same as the
destination address of the individual message that is being packed. Making
clever use of '*' for (parts of) the address will allow you to do routing
of messages.
The third parameter is optional and, when used, specifies the packet
password to use when creating the mailpacket.
Currently, NetMgr will properly:
- Request files (make a *.REQ file in the outbound).
- Attach files (make an *.?LO file). FLAGS KFS (Kill file after it is
sent) & TFS (truncate file after it is sent) are supported.
- Pack (bundle and put in outbound, not compress) messages (make and/or
add to *.?UT files in outbound).
- Strip paths from subject lines of 'file attach' messages.
- Handle update requests.
- Handle (update) requests with passwords.
- Generate and check for busy (*.BSY) flags in the outbound.
The packing is dumb. NetMgr will happily pack messages to yourself, for
example. Or route files to an overseas system, even if they are not coming
from your system. Or route file requests.
Like all other commands, NetMgr simply scans headers and does what it's
told, the logic of it's actions has to come from YOU.
The only 'intelligence' of the packmail function:
■ It will not pack messages that are 'sent' or 'locked'.
■ It will automatically set the 'sent' bit after sending.
■ If the message is 'kill/sent', it will delete the message after it is
successfully added to the mailpacket in the outbound area.
Here are the four main forms will most likely be used for the PackMail
action:
PackMail <address> * : Send/Route messages to the destination
address found in message header (even if
it's a point!). This would be applicable
for 'hold' mail to/for points.
PackMail <address> <address b> : Send/Route messages to address b. All
messages, regardless of their destination
address, will be routed to <address b>.
This would be applicable for normal
flavour mails, that can be routed to a
Boss or HUB node.
PackMail <address> *:*/*.0 : Send/Route messages to the second
address, with the pointnumber always set
to 0 (in other words: do Bossrouting for
this entry). This would be applicable for
'crash' mail for points. Most points do
not run a continuous mail system (usually
you don't even know a phonenumber), so a
crashmail for a point would usually have
to be delivered at the point's Bossnode.
PackMail <address> *:*/0.0 : Send/Route messages to node 0 in the net
of the destination address found in the
header (HostRouting).
You can also use '@myaka' instead of 'address' as the origination
address. This will let NetMgr pick the most appropriate AKA
automatically. See the special section about AKAmatching later in the
documentation.
■ MOVEMAIL <orig> <dest> <dir> [<password>]
───────────────────────────────────────────
<orig> : origination address to use (in mailpacket header).
<dest> : destination address to use (in mailpacket header).
<dir> : output directory for packet.
<password> : packet password to use for the mailpacket (optional).
This will create a mailpacket, not in Binkley's outbound but in the <dir>
you specify. The packetname will be a unique name created by NetMgr (it
is an uncompressed packet, so the extension will be .PKT). The packet
will be from <orig> and addressed to <dest>.
You can also use '@myaka' instead of 'address' as the origination
address. This will let NetMgr pick the most appropriate AKA
automatically. See the special section about AKAmatching later in the
documentation.
Using '*' for <dest> is not allowed here (I don't think it is useful - it
can be added though).
If a file is attached to the message, it will be copied to <dir> as well.
The FLAGS KFS & TFS are respected; after the file is copied it will be
deleted or truncated if one of these flags is set.
The 'sent' bit is set after the message is added to the mailpacket, or
the message is killed (when a message was marked kill/sent).
Messages that are either Sent or Locked will not be processed.
Possible uses: mail delivery through a LAN, maybe also sending mail to
gateways on your system.
■ RUNEXTERNAL <program to use> <parameters>
───────────────────────────────────────────
This action allows you to run an external program from NetMgr. Before
running the external program, NetMgr will swap most of itself out of
memory (DOS version), leaving plenty of room for other programs to run.
In the <parameters> part, you can make use of several 'variables', whose
value depends on the contents of the header of the message that triggered
the action. The following variables are available:
from - Name in the 'from' field of current message.
to - Name in the 'to' field of current message.
subject - Name in the 'subject' field of current message.
orig - Origination address of current message (like 2:281/527).
dest - Destination address of current message (like 2:281/527).
areadir - Directory or base name of current area, board number if
Hudson. This is in the format that is also used in
NetMgr.cfg, so $<path+basename> for a Squish area,
!<path+basename> for a JAM area etc.
msgno - Message number of current message ('relative' number for
Squish and Hudson)
realmsgno - Real message number, for Squish (UMSGID) and Hudson (real
number in Hudson base, not the relative number in the area).
For JAM and *.MSG, this is always equal to msgno.
file - Name of the file that contains the body of the message.
newfile - Name of a new file to create if you want to replace the body
of the message with new text.
repfile - Name of the file that should be created if you want to send
a message back to the sender of the message. (See below).
attach - Files attached to this message (list of files).
request - Files requested in this message (list of files [!passwords]).
Before running the external program, NetMgr will write the body of the
message to a file. This file (and other files) will be created in the
directory where NetMgr found it's config file. The path+name of this file
is available through the variable [file]. It will be:
"<path to config file>\netmsg.msg".
NetMgr will then run the external program, and afterwards check for the
existence of two files:
■ "<path to config file>\netmsg.new" : if this file exists, NetMgr will
replace the body of the message with the contents of this file. The
path+name of this variable is available through the variable
[newfile].
■ "<path to config file>\netmsg.rep": if this file exists, NetMgr will
send a message back to the sender of the message that triggered this
action.
What is actually done, is an XEMPTYBOUNCE action. For this action, the
netmsg.rep file is used as the body (where the variables like [from],
[to] etc. can be used), but where the first line of this .rep file is
used as the 'mask' for the reply header.
Because it actually _is_ an XEMPTYBOUNCE, it also follows the same
conventions as the XEMPTYBOUNCE action, so it initializes the fields
with a standard reply header, which makes it possible to use a simple
'*, *, *, *, *, *' mask (see XEMPTYBOUNCE action for more info).
The path+name of this variable is available through the variable
[repfile].
An example:
Action RUNEXTERNAL pgp.exe +batchmode -sta -u art -o [newfile]
-z pass [file]
could expand to:
'pgp.exe +batchmode -sta -u art -o c:\net\netmsg.new -z pass
c:\netmgr\net.msg'
This would run PGP on the message, and sign the text. The body of the
message will be replaced with a signed version of the text.
An example of usage of a .rep file could be:
Action RUNEXTERNAL reply.cmd [repfile]
And the contents of 'reply.cmd' could be:
@echo off
echo Automatic Reply, @myaka, *, *, Response to your message, * >> %1
echo Hello %%ffrom! >> %1
echo. >> %1
echo This is an automatic reply! >> %1
echo. >> %1
echo Greetings! >> %1
For DOS users, 'reply.cmd' should of course be 'reply.bat'.
This would create a netmsg.rep file, and NetMgr would send back a small
message to the sender of the original message.
■ Display <line to display>
───────────────────────────
This one will display a line of text on the screen and in the logfile.
You can use this to add details about certain actions to the logfile.
Example:
Mask *, *, Pietje Puk, *, *, *
Action Display Deleted message to Pietje Puk!
Action Delete
Whenever this action is executed, the line 'Deleted message to Pietje
Puk!' will be shown on the screen and added to the logfile. Leading and
trailing spaces are not touched, the line is displayed exactly as found
in the config (The first space, between 'Display' and 'Deleted' in this
case, *does* of course get stripped..).
Please note that some actions prevent NetMgr from looking for more
actions to perform. Delete is one of them: after a message is deleted,
there is nothing that can be done with that message anymore and NetMgr
stops scanning for more actions. (Echo-)move is another example.
Of course, 'Display' is something that *can* be done even after a message
is deleted, it is an exception to this. But NetMgr is not that smart, so
keep it in mind and do the 'display' first.
So this:
Mask *, *, Pietje Puk, *, *, *
Action Delete
Action Display Deleted message to Pietje Puk!
Doesn't work, because NetMgr will never get to the 'Display' action.
Some other examples of Action statements.
=========================================
--
Action Delete
Delete the message
--
Action Move $c:\bink\msgs\net2
Move a message to the Squish style (leading $) area c:\bink\msgs\net2.
--
Action Move c:\msgs\rec_msg
Move a message to the *.MSG style (no leading $, ! or #) area
c:\msgs\rec_msg\.
--
Action Copy !c:\jammsgs\saved
Copy a message to the JAM style (leading '!') area c:\jammsgs\saved.
--
Action Rewrite *, *:*/*.0, *, *, *, *
Change a message header.
Any field that has a '*' will be left untouched (in this case the
Fromname, the fromaddress zone, net and node parts), the toname, the
toaddress and the attributes.
So, to be more precise: only the point number of the message sender will
be changed. Messages coming from 2:281/527.40, for example, will be
changed to a message coming from 2:281/527.0.
--
Action ReWrite *, *, Pietje Puk, *, *, *
This will rewrite the 'toname' part of a message, it will put "Pietje Puk"
in the TO: name-field.
--
You can also tell NetMgr to change the attributes of a message. Again, any
attributes must be preceded by a '+' or '-'.
A '+' in this case means: set this bit.
A '-' in this case means: turn this bit off.
so..
+p+l+k-c-f
.. will turn ON the P)rivate, L)ocal and K)ill bits, and turn OFF the
C)rash and F)ile request bits. Other attributes are left untouched.
Examples:
Action Rewrite *, *, *, *, *, -c+p
Turn off the crash bit for that message. Turn ON the P)rivate bit.
Action Rewrite *, *, *, *, *, -c-a-f-d-m-t-e-z+h+p+k
Turn off the crash, attach, request, direct, immediate, Truncate file
sent, Kill file sent and Archive file sent bits for that message. Turn ON
the P)rivate bit, K)ill bit and H)old bit. This could be used to strip all
'dangerous' bits off a message an make sure it is a private message that
will be put on hold for pickup. It might be useful to perform an action
like this on all message that you are routing for someone else, for
example.
--
Action Bounce 2:281/527.0 nojoe.txt
This will write a bounce-message (a message that is addressed to the
sender of that message), the message body will contain the header and body
of the original message. The address 2:281/527.0 is used as origination
address for this message.
Also, NetMgr will add the contents of a textfile at the top of the
body. In this case the contents of the file 'nojoe.txt' will be added.
The contents could be:
-=- <begin> -=-
Sorry, but Joe's modem had a heart attack, so he is currently not
available. The message you wrote will remain 'on hold' until he has a new
modem.
The original text of your message:
::::
-=- <end> -=-
And that will be added at the top.
The original message will NOT be deleted. If that is what you want, you
must add the another ACTION for that MASK, to DELETE the message.
NetMgr accepts more than one 'ACTION' for a certain mask.
You can also, for example, first rewrite a message, and then move it, etc.
--
Action EchoCopy 2:281/527.0 #57 281/527 528
This will copy a message to the Hudson style area, board number 57, and
add 281/527 528 to the SEEN-BY. The text listed will be copied literally,
so be VERY CAREFUL what you specify here! Test it thoroughly (together
with any downlinks) before using it!!
The newly created echomail message will show 2:281/527 as its origination
address in the origin.
--
Action File c:\msgs\netmsgs.txt
This will write out a message to the file c:\msgs\netmsgs.txt. If the file
doesn't exist, it will be created. If it does exist, the message will be
appended to the file.
--
Action UUCPrewrite *, *, postmaster, 2:281/527.0, *, +p+k+l
This will take the name from the TO: field, and add it at the top of the
message body (TO: <toname>). The message itself will be readdressed to
postmaster at 2:281/527, and have the attributes p)rivate, k)ill and
l)ocal added.
This can be useful for people who gate messages to internet.
--
Action Semaphore c:\frodo\sems\areafix.sem
This will create (or touch) a semaphore called areafix.sem. You may use
this to create semaphores that will start Areafix only when a message to
areafix was actually encountered by NetMgr (as opposed to running areafix
after every mailtoss).
┌───────────────────────────────┬───────────────────────────────────────
│ MASK and ACTION in NetMgr.cfg │
└───────────────────────────────┘
A MASK must *always* have one or more corresponding ACTION(s) in
netmgr.cfg. NetMgr will NOT run if anything is wrong in the config.
Whenever you make any changes to the configuration file, please give it a
test run to see if any syntax errors pop up.
There are always 'pairs':
Mask *, *, Harry Twit, *, *, *
Action Delete
Any message that matches the MASK will be deleted.
--
Mask *, *, *, 60:*/*.*, *, *
Action Move !c:\bink\msgs\net2
Any message addressed to a zone 60 address will be moved to the specified
JAM area.
--
Mask *, *, *, *, *, +r
Mask Move $c:\msgs\received
All received messages will be moved to the specified Squish area.
--
Mask *, 2:281/527.0, *, *, *, +f
Action Packmail 2:281/527.0 *
This takes all file request messages, generated by 2:281/527, and
properly generates a request out of it. The request will be addressed to
the system that is also found in the 'destination address' field of the
message (that makes sense) :-)
Mask *, 2:281/527.0, *, 1:*/*.*, *, +l
Action Packmail 2:281/527.0 1:138/211.0
This will take all messages from 281/527, addressed to any zone 1 system,
and pack them in a mailpacket addressed to 1:138/211.
Mask *, 2:281/527.99, *, *, *, +l-c-h-d-a-f-u
Action Packmail 2:281/527.99 2:281/527.0
This will take all messages that originate from 2:281/527.99, that have
the local bit set, and that are NOT crash, hold, direct, file attach, file
request or update request. In other words: all 'normal' messages. These
message are packed in a packet addressed to 2:281/527.0.
In effect, all 'normal' messages would be routed to 2:281/527.0. And
considering that 2:281/527.99 is a point off of 2:281/527, that makes sense:
all normal messages are routed through the Boss node. File requests, crash
messages and such are not: they need to be sent directly to the
destination. That could be done with the following Mask/Action lines:
Mask *, 2:281/527.99, *, *, *, +l
Action Packmail 2:281/527.99 *:*/*.0
If the above line would be placed in NetMgr.cfg *below* the Mask we just
saw, we would only get to this mask if the message is indeed crash or file
request and the like: otherwise they would already have been packed with
the previous Mask/Action.
This mask takes all message originating from 2:281/527.99 with the local
flag set, and routes them to the Bossnode of the system found in the
destination address of the message.
For file requests, crash messages and comparable types of messages, this
is usually the correct action: requests have to be dropped at the system
directly in order to get the files. Crash messages are usually not routed
(because you want to deliver them ASAP).
And because points usually don't have a system online at all times, the
messages are routed to the Bossnode (that often is online at all times)
of that point.
It is also possible to specify SEVERAL actions for one mask:
Mask *, *, Pietje Puk, 2:281/527.0, *, *
Action Bounce 2:281/527.0, c:\txt\newaddr.txt
Action File c:\msgs\pietje.txt
Action Forward Art, 2:281/527.0, Pietje Puk, 2:300/1.0, Readdressed mail, +l
Action Delete
Take a while to check this out. What it does is this:
Whenever a mail addressed to 'Pietje Puk' on 2:281/527 is encountered,
this message will be bounced back to the sender. The contents of the file
'c:\txt\newaddr.txt' will be added at the top of the message (possibly
explaining that Pietje now has a new email address).
Then, the contents of the message will be written to a file (pietje.txt).
The message will also be forwarded to 'Pietje Puk' on '2:300/1', which is
Pietje's new netmail address (so he gets his message anyway).
And finally, the original message is deleted.
You can also use more than one Mask, and combine it with one or more
actions!
For example:
Mask Gerard van Essen, 2:281/527.0, *, *, *, +s
Mask *, *, Gerard van Essen, 2:281/527.0, *, +r
Action Move $c:\fastecho\rcvdsent
This will take all messages FROM Gerard van Essen (2:281/527) that are
'sent', and also all message TO Gerard van Essen (2:281/527) that are
received and moves these to a Squish message area (rcvdsent). In other
words: all received and sent netmail is moved out of my primary netmail
area.
This means, that either the first Mask has to match, OR the second mask
has to match. If either of them matches, he action will be performed. This
is known to confuse users, if you also use 'NOT' in a certain mask. Some
examples will hopefully clear this up a bit:
Mask Gerard van Essen, *, *, *, *, *
Action Delete
This will delete a message if it is written by Gerard van Essen.
Mask !Gerard van Essen, *, *, *, *, *
Action Delete
This will delete a message if it is NOT written by Gerard van Essen.
Mask Gerard van Essen, *, *, *, *, *
Mask Pietje Puk, *, *, *, *, *
Action Delete
This will delete a message if it is written by Gerard van Essen, OR if it
is written by Pietje Puk. If any of the two masks match, the action will
be performed.
Mask !Gerard van Essen, *, *, *, *, *
Mask Pietje Puk, *, *, *, *, *
Action Delete
This will delete a message is it is NOT written by Gerard van Essen, OR if
it is written by Pietje Puk. If any of the two masks match, the action
will be performed.
In this case, a message written by 'Gerard van Essen' does not match the
first mask (that one matches only messages that are NOT written by Gerard
van Essen), nor does it match the second mask (that one only matches
messages written by Pietje Puk). The 'Action Delete' will not be
performed.
A message written by 'Jos Verstappen' does match the first Mask (Jos
Verstappen is 'NOT Gerard van Essen' so that is a match with the first
mask. The 'Action Delete' is performed.
Mask !Gerard van Essen, *, *, *, *, *
Mask !Pietje Puk, *, *, *, *, *
Action Delete
This will delete a message if it is NOT written by Gerard van Essen, OR if
it is NOT written by Pietje Puk. If any of the two masks match, the action
will be performed.
In this case, a message written by 'Gerard van Essen' does not match the
first mask (that one matches only messages that are NOT written by Gerard
van Essen), but it does it match the second mask (that one matches
messages NOT written by Pietje Puk). And since 'Gerard van Essen' is 'NOT
Pietje Puk', it matches the second Mask.
The 'Action Delete' will be performed.
A message written by 'Jos Verstappen' does match the first Mask (Jos
Verstappen is 'NOT Gerard van Essen' so that is a match. The 'Action
Delete' is performed.
As you can see, ANY message matches one of the above masks!
If a message is written by "gerard van essen", it will match the second
mask.
If a message is written by "pietje puk", it will match the first mask.
If a message is written by anyone else, it will match either of the masks.
So a message always matches at least one of the masks. With the above
example, all messages in the netmail area would be deleted.
Finally, you can also combine several masks with several actions.
Mask Gerard van Essen, 2:281/527.0, *, *, *, +s
Mask *, *, Gerard van Essen, 2:281/527.0, *, +r
Action File c:\msgs\oldmail.txt
Action Delete
This will write all received and sent netmail to a file, and then delete
it.
┌─────────────────────────┬────────────────────────────────────────────
│ NetMgr's scanning logic │
└─────────────────────────┘
For each message found in the netmail area, NetMgr will scan the defined
masks (for a certain 'ScanDir', see below) and check whether any of them
matches.
As soon as a match is found, all 'Actions' for that 'Mask' are performed
(you can have more than one action for each Mask, as you now know).
After all these Actions are performed, NetMgr will *not* scan for any more
matching masks. It will simply go to the next message in the netmail area
and start scanning for a match for that next message again.
This means, that if you have TWO masks that actually match a certain
message, only the first one that is encountered will be found (and as a
result only the actions that belong to that first mask will be performed).
As an example, take these two mask/action combinations:
Mask *, *, Pietje Puk, *, *, *
Action Copy c:\fd\netmail
Mask *, *, *, *, *, +c
Action ReWrite *, *, *, *, *, -c
Clearly, the user wants to reset all 'crash' bits with the second
mask/Action combination.
However, whenever a message to 'Pietje Puk' is encountered, NetMgr will
perform the action for that mask (and copy the message to c:\fd\netmail)
and then stop scanning.
So in that case, the second mask will never be evaluated. Even if it does
match (a crashmail message), the action for the second Mask will never be
performed. If a message to Pietje Puk is marked as 'crash', it will be
copied to the netmail area with the crash bit set.
If you want to reset the crash bit, even for message to Pietje Puk, you
can simply add the rewrite to the first mask as well, like this:
Mask *, *, Pietje Puk, *, *, *
Action ReWrite *, *, *, *, *, -c
Action Copy c:\fd\netmail
Mask *, *, *, *, *, +c
Action ReWrite *, *, *, *, *, -c
In this case, even messages to Pietje Puk will have their crash bit reset.
Using this technique, anything you want can still be done. Just copy the
Action statement and add them to the other masks as well.
┌────────────────────────┬──────────────────────────────────────────────
│ eXtended Masks (XMASK) │
└────────────────────────┘
NetMgr offers another kind of mask: the eXtended mask (XMASK). As the
name implies, these masks offer more than a standard mask. Xmasks allow
the user to specify more criteria for the search.
If this is the first time you are looking into NetMgr, it might be a
good idea to either skip this section, or just glance through it a bit
to see what is possible.
You can do a lot with just standard masks, and it might be wise to play
around with them a bit before going a step further and dive into
extended masks as well.
XMASKS take a bit more room than a standard mask. They can be used
together with standard masks (even mixed within the same config).
To define an extended mask, use the XMASK keyword. An XMASK definition
always starts with this keyword, and always ends with a line with only
'End' on it. Between these two lines, search criteria are defined.
An example:
Xmask
from Gerard van Essen
End
This defines an XMASK, that looks for messages that are FROM: 'Gerard
van Essen'.
You can specify more than one criterion. The number of criteria allowed
for a mask is only limited by available memory.
For a message to be a match, it must satisfy _all_ requirements that are
defined. So, if you have:
Xmask
from Gerard van Essen
to pietje puk
End
A message is only a match when it is from 'Gerard van Essen' _and_ to
'pietje puk'.
The following keywords can be used in an XMASK:
from - who the message is from
to - who the message is to
subject - the subject of the message
attr - attributes of a message (like +a-p etc, like a standard mask)
kludge - a search text to be found in the kludges of a message
body - a search text to be found in the body of a message
bodybytes <n> - how many bytes of the message body must be searched to find
the string(s) specified to find in the body.
bodylines <n> - how many lines of the body to search, or actually
paragraphs, separated by a CR (ASCII 13, '\r').
orig - origination address of the message (like 2:281/527.0 - always 4D)
dest - destination address of the message (like 2:281/527.0 - always 4D)
olderwritten <n> - 'Date written' of the message must be older than n days.
olderprocessed <n> - 'Date processed' of the message must be older than n
days (JAM, Squish, SDM).
olderread <n> - 'Date msg read by recipient' of the message must be
older than n days (JAM only).
When searching for a string (from, to, subject, body, kludges), you can
also enclose a string in either single or double quotes. This gives you
the opportunity to search for trailing and/or leading spaces.
Even when quotes are used, the ~ (substring) and ! (NOT search) tokens
are still supported, just like in normal MASKs. These tokens must be
entered inside the quote, so "~gerard" will look for the substring
'gerard' to be present anywhere.
AND and OR searches.
--------------------
Specifying a certain keyword more than once, gives you an AND search. As
mentioned before, _all_ requirements that are defined must be met. So
specifying ...
Xmask
body "gerard"
body "timed"
End
... will look for messages that have 'gerard' AND 'timed' in the body.
However, you can also do an OR search, by specifying more than one
element on the same line, always enclosed in quotes and separated by the
OR keyword, like this:
Xmask
body "gerard" OR "timed"
End
This will look for messages that have 'gerard' in the body, OR that have
'timed' in the body.
You can also do a similar thing with addresses:
Xmask
orig 2:*/*.* OR 1:*/*.*
End
This will look for message originating from either zone 2 or zone 1.
You can also do an AND search with addresses:
Xmask
orig 2:*/*.*
orig !2:281/527.*
End
This will look for messages originating from zone 2, and NOT from node
2:281/527 or any of its points.
NetMgr also allows the OR construction for attributes. So something
like this is also possible:
XMASK
From Gerard van Essen
Orig 2:281/527.0
Attr +c OR +a+l OR +f-c
END
This mask will match all messages that are flavoured crash, or are
flavoured 'attach' and 'local', or flavoured 'request' but NOT crash.
Please note that this construction is not valid for the attributes that
need to search the nodelist (# and @). You can specify these attributes
like this, but they are checked once, separately from the other
attributes.
So you cannot specify:
Attr +c-@ OR -c+@
or something similar. You can only specify these attributes once and they
will then be carried over to all other attribute masks. In other words,
specifying this:
Attr +c-@ OR +l
will actually be expanded to:
Attr +c-@ OR +l-@
Using files as input for a search item.
---------------------------------------
Finally, for from, to, subject, kludges, body, orig and dest, you can
also specify a filename as input. The filename must be preceded by a
'<', like this:
to <c:\data\names.txt
The file itself should consist of a number of lines, all with one
string/address to look for. If any of the strings/addresses are found,
this will be considered a match (so that is an 'OR' search).
In the case of the example with names.txt above, the file could look
like this:
-=-
Areafix
Areamgr
SQafix
-=-
Any message addressed to 'Areafix', OR 'Areamgr' OR 'SQafix' will be a
match.
Leading and trailing spaces on a line in the file will be stripped.
Quotes are not allowed. However, use of the '~' and '!' tokens _is_
allowed.
Using an XMASK.
---------------
One or more XMASKs must be combined with one or more actions (they are
just like a standard MASK in this respect):
XMASK
from Gerard van Essen
End
Action Delete
So apart from the fact that an XMASK is spread over more than one line,
using it a the same as a standard MASK.
You can also define an XMASK, give it a name, and use it later on in the
.cfg file. To define an XMASK, use the 'DefineXmask' keyword:
DefineXmask <mask name>
...
<mask criteria>
...
End
Like this:
DefineXmask personal
to "Gerard van Essen" OR "gerard van.essen" OR "art" OR "Geer art"
End
Later on, you can then use the XMASK named personal again:
XMASK personal
Action Move $c:\mail\personal
This gives you the opportunity to make the Mask/Action combination a bit
more compact and (hopefully) clear.
The ability to define XMASKs without a directly connected action is also
exploited to allow posting messages from the command line (see special
section about this).
┌────────────────────────────────────┬─────────────────────────────────
│ Areas to scan: the ScanDir keyword │
└────────────────────────────────────┘
There's one more important keyword in NetMgr.cfg, and that's the ScanDir
keyword.
This will give NetMgr an area to Scan for messages that match a Mask.
Example:
ScanDir c:\fd\netmsgs
The default is a *.MSG area, but:
A '$' in front of an area indicates a Squish style area.
A '!' in front of an area indicates a JAM style area.
A '#' in front of an area indicates a Hudson style area.
You can have as many of these as you like, NetMgr will scan each and every
one of them. But, just as a certain action is related to a certain mask,
certain action/mask combinations are related to a ScanDir statement.
When a ScanDir statement is found in NetMgr.cfg, all Mask/Action
combinations following that ScanDir up to the next ScanDir statement will
(only) be valid for that particular ScanDir.
ScanDir c:\fd\netmail
Mask A
Action ..
Action ..
Mask B
Action ..
Mask C
Action ..
ScanDir c:\fd\usenet
Mask D
Action ..
In the above example, c:\fd\netmail will be scanned for Mask A, B and C,
but not for Mask D.
c:\fd\usenet will (only) be scanned for Mask D.
You can also specify more than one ScanDir, followed by one or more Masks.
All ScanDirs will be scanned for those masks.
ScanDir c:\fd\usenet
ScanDir $c:\fd\netmail
Mask E
Action
In the above example, both c:\fd\usenet and $c:\fd\netmail will be scanned
for mask E.
Renumbering *.MSG areas.
------------------------
For *.MSG areas, you can specify the optional 'renum' keyword when you
define the area using the 'ScanDir' keyword.. After scanning the area,
NetMgr will then renumber the area (and adjust the lastread pointer
when necessary).
Example of such a definition:
ScanDir c:\fd\netmail renum
┌───────────────────────┬───────────────────────────────────────────
│ Automatic AKAmatching │
└───────────────────────┘
NetMgr has AKAmatching capabilities, that can be used in several
places.
In order to let NetMgr do this, add all the addresses you might want to
use to NetMgr.cfg (multiple 'homeaddress' statements are allowed).
By default, NetMgr can do the matching for you without any further info.
This option is interesting if you have more than 1 address.
NetMgr can then be ordered to find the most appropriate address to use
when writing a message.
Say, for example, that you have two addresses: 2:281/527 and
60:100/112.
If you write a messages to 2:500/133, you probably want to use
your 2:281/527 address.
If you write a message to 60:100/1, you probably want to use
your 60:100/112 address.
In this case, NetMgr would try to find the address (AKA) that 'matches'
the destination address best.
It first looks for a matching zone, and if more than one match
is found, it'll try to find an address where both 'zone' and
'net' match. If there is still more than one match after that,
it will just take the first match.
If you want to make exceptions to these matching rules, or if you want to
do AKAmatching _within_ a certain net, you can force NetMgr to use
certain AKA by using the AKAFORCE keyword in NetMgr.cfg.
Where does it work?
First of all, NetMgr can pick the correct AKA to use when generating a
new message using one of the BOUNCE, XBOUNCE, MakeMsg or Forward
actions.
In order to let NetMgr pick an appropriate address, use '@myaka' instead
of a 4D address. For example:
Action Bounce @myaka c:\txt\bounce.txt
Or:
Action Xbounce c:\txt\bounce.txt The Bouncer, @myaka, *, *, Go away!, *
You can also use the AKA matching with REWRITE. This is probably only
useful when you are currently using NetMgr already to do AKAmatching with
several masks. You may now be able to do it with one mask/action:
Mask Gerard van Essen, *, *, *, *, +l
Action Rewrite *, @myaka, *, *, *, *
Finally, you can also use it for the PackMail and MoveMail actions, for
the origination address:
Action PackMail @myaka *
This will pack all mail directly to their destination, and use a matching
AKA in the packet header as origination address. Please note that this
(obviously!) does not have any effect on the addresses used within the
packed messages! Only the packet header is affected by this!
┌──────────────────────────────┬────────────────────────────────────
│ Other keywords in netmgr.cfg │
└──────────────────────────────┘
HOME
====
Example:
Home 2:281/527.0
Your address. The zone is used as a default value for 'zoneless' messages
(only *.MSG style areas).
It is also used for Binkley style netmail packing: netmail for the zone of
the 'home' address is placed in the directory defined with the 'OutBound'
keyword in NetMgr.cfg.
It is allowed to put in this statement more than once. This can be
useful if you want to use NetMgr's AKAmatching capabilities (see
special section on AKAmatching elsewhere in this document).
ORIGIN
======
Origin NetMgr, (c) 1992-'94 Gerard van Essen
An origin line, will be used for EchoCopy and EchoMove.
INTLFORCE
=========
If you add this to your NetMgr.cfg, timEd will _force_ an INTL kludge
on any netmail it somehow writes (this includes messages touched
through a REWRITE, COPY/MOVE etc).
AKAFORCE
========
Format:
AKAFORCE <mask> <address to use>
With this statement, you can influence NetMgr's AKAmatching
capabilities. In several places, you can let NetMgr do AKAmatching
automatically. However, in some cases the automatic matching might not
come up with the address you wanted. With AKAforce, you can force
NetMgr to use a certain address in certain situations.
example:
AKAFORCE 50:*/*.* 49:500/1
This means: always use 49:500/1 as address when mail is sent to any zone
50 address. This forcing will take precedence over 'automatic'
akamatching.
LOG
===
Log c:\tc\netmgr\netmgr.log
The location and name of your logfile. Leave this keyword out if you don't
want a logfile.
FRODOLOG
========
If the keyword 'Frodolog' is included in NetMgr.cfg, NetMgr will generate
a logfile that looks like the logfile that FrontDoor generates. If you
leave this keyword out, NetMgr will generate a Binkley style logfile.
JAMLOG
======
For JAM areas, NetMgr now write NETMAIL/ECHOMAIL.JAM. Add the keyword
'JAMLOG' to NetMgr.cfg and give the directory to put the files in.
Example:
JamLog c:\fd\msgbase\
HUDSONPATH
==========
The location of your Hudson message base. Use this only if you actually
have a Hudson base.
Hudsonpath C:\Tosser\Msgbase
NODELIST
========
This gives the path to the Version7 nodelist. You may need this keyword if
you want to use the special nodelist attributes ('@' and '#') that NetMgr
supports to check whether an address is listed in the nodelist or not.
Leave this out if you do not have a Version 7 nodelist.
FDNODELIST
==========
This gives the path to the Frontdoor or Intermail nodelist. You may need
this keyword if you want to use the special nodelist attributes ('@' and
'#') that NetMgr supports to check whether an address is listed in the
nodelist or not. Leave this out if you do not have a FrontDoor or
Intermail nodelist.
GIGONODELIST
============
This gives the path to the GIGO nodelist index. You may need this keyword
if you want to use the special nodelist attributes ('@' and '#') that
NetMgr supports to check whether an address is listed in the nodelist or
not. Leave this out if you do not have a GIGO nodelist. NetMgr includes a
special compiler made by Jason Fesler (1:203/7707) to generate GIGO
indexes.
The GIGO index is pretty small (less than 100 kB for the current world
nodelist), so if you do not have a Version7 nodelist nor a Frontdoor
nodelist, you might want to make one.
NODELISTCACHE
=============
To speed up nodelist access to regularly checked nodes, there is a simple
cache system for the nodelist checking: the last few nodes that were
checked in the nodelist will be cached in a small file that is saved to
disk at exit. For a new run, NetMgr will read this file and keep it in
memory to check it before actually doing a lookup in the nodelist on
disk. The number of nodes that are 'remembered' in such a way is
configurable with the keyword 'CacheSize' (see below).
The 'NodeListCache' keyword gives a path (not a filename, just the path)
to store this 'cache file' with nodes. The name of this file will always
be 'nodes.buf'.
* Important: When you update/recompile your nodelist, erase the 'cache
file', as the data that is cached may be invalid after the nodelist
update! A node that is marked as 'unlisted' in the cache, may actually
be listed after the nodelist is updated, and v.v.!
CACHESIZE
=========
With this keyword you can define the number of nodes to keep in the
nodelist cache. If you usually have mail to 100 different addresses in
your netmail area, set it to at least 100.
Example:
CacheSize 250
OUTBOUND
========
This has to point to your Binkley style primary outbound directory. It is
required if you want to use the netmail packing capabilities that NetMgr
offers (PackMail action).
NetMgr can create names for outbound directories other than the default
zone (names like: C:\BT\OUT.006) itself, so one 'OutBound' statement is
all you need to specify in order to send mail to all zones.
Domains are not supported.
Example:
OutBound c:\bt\out
If my the zone of my primary address (as specified in the Home keyword in
NetMgr.cfg) is for example 2:, this will put all mail for zone 2: in the
directory "c:\bt\out". Mail for zone 1 will be put in "c:\bt\out.001" etc.
┌──────────────────────────────────────────────────┬───────────────────────
│ Posting files as a message from the command line │
└──────────────────────────────────────────────────┘
In order to post a file as a message, use the POST command on the
commandline.
To do a post, you first need to define an XMASK with DefineXMask in
NetMgr.cfg. In that mask, specify "from", "to", "subject", and "orig" for
echomail messages. For netmail messages, you need to add "dest" as well.
Adding 'attr' is allowed, but not required. If you don't specify any
attributes, NetMgr will default to (only) the 'local' attribute.
When generating the message, NetMgr will use the info in this XMASK to
generate the header for the message.
On the command line, you specify which xmask to use, what file to use as
body, the area to post in, and whether or not the area is an echomail
area. To do this, the following command line options are available:
-x : specify XMASK to use
-a : specify area to use (use leading !, # or $ to indicate msgbase format)
-e : specified area is an echomail area
-f : ASCII file to use as body for the message
Full example:
Provided the following XMASK is defined in NetMgr.cfg:
DefineXmask netpost
from Gerard van Essen
to NetMgr User
subject Answer to your query
orig 2:281/527.0
dest 2:2/0.0
End
The following command line...
NetMgr POST -xnetpost -a$c:\fd\netmail -fc:\txt\canned.rep
... would generate a new netmail message in the Squish style area
'c:\fd\netmail', with the header specified (i.e.: to 'NetMgr User', from
'Gerard van Essen' etc), and with the textfile 'c:\txt\canned.rep' as
the body.
NetMgr will start up, read the config, open the area, post the message,
and then exit immediately (without scanning the netmail area as is
normally done).
When the -e command line parameter is used, NetMgr will add tear- and
origin lines as well.
Provided the following XMASK is defined in NetMgr.cfg:
DefineXmask rules
from Moderator
to All
subject The monthly rules
orig 2:281/527.0
End
The following command line...
NetMgr POST -xrules -a!c:\echo\artware -fc:\txt\artware.rul -e
... would generate a new echomail message in the JAM style area
'c:\echo\artware', with the header specified (i.e.: to 'All', from
'Moderator' etc), and with the textfile 'c:\txt\artware.rul' as the body.
┌───────────────────────────────────┬─────────────────────────────────────
│ Binkley style outbound management │
└───────────────────────────────────┘
NetMgr also offers some outbound management capabilities, usable from
the command line. You can use one of the following commands on the
command line:
■ POLL : create a poll packet for a certain node.
■ GET : create a filerequest for a certain node.
■ UPDATE : create an update request for a certain node.
■ SEND : create a file attach for a certain node.
■ CHANGE : change mail status for mail waiting for a certain node.
To support this, the following command line options are used:
-s : Status (also called 'flavour') of request/attach.
-n : New status for mail (used for 'CHANGE').
-p : Password to use for file request.
-# : Node address of node to request files from / send files to.
-f : File to send/request.
The 'POLL' command needs: -# and -s.
The 'GET' command needs: -#, -f and -s (optional: -p).
The 'UPDATE' command needs: -#, -f and -s (optional: -p).
The 'SEND' command needs: -#, -f and -s.
The 'CHANGE' command needs: -#, -s and -n.
For the '-s' and '-n' options, the following flavours can be used:
normal, crash, imm, hold, dir.
Examples:
NetMgr POLL -#2:281/527 -scrash
Poll node 2:281/527, crash status.
NetMgr GET -#2:500/133 -fnewfiles -shold -psecret
Request from node 2:500/133, with 'hold' status, the file 'NEWFILES' and
use 'secret' as password for this request.
NetMgr SEND -fc:\autoexec.bat -simm -#1:138/211
Attach the file c:\autoexec.bat, with 'immediate' status, to 1:138/211.
NetMgr CHANGE -snormal -ncrash -#2:281/527.5
Change the flavour of all mail destined for 2:281/527.5 flavoured
'normal' to a new flavour of 'crash'.
For any of the above to work, you need to have the 'OutBound' keyword
defined in NetMgr.cfg.
┌───────────────────────────────┬─────────────────────────────
│ Other Command line parameters │
└───────────────────────────────┘
There are three other command line parameters:
-D
For 'debugging' purposes you can start netmgr with the -d command line
switch. This will send NetMgr's interpretation of your config file to
stdout.
While scanning your netmail area, it will also send some info about the
headers of the messages to stdout.
You can easily redirect it to a file (netmgr -d > debug.txt) for
inspection.
In case of any problems with NetMgr, use this switch to determine what
exactly is the problem!
--
-C
Here you can specify the name of an alternative Config file. For example:
NetMgr -Cc:\netmgr\mycfg.txt
--
-Q
Enables 'quiet' mode. Hardly anything is written to the screen in this
case. This speeds up processing a bit.
┌─────────────┬─────────────────────────────────────────────────────────
│ Errorlevels │
└─────────────┘
Three possibilities:
0 : No errors, no work done.
1 : No errors, something done (move, copy, bounce or whatever. Anything.)
254 : Error occurred (out of memory, config error etc).
Some bits and pieces..:
* NetMgr was compiled using Watcom C/C++ v10.5.
* NetMgr source code is not and will not be available.
The author can be reached...
The best thing is to hook into the ARTWARE support echo. I give support for
my products there. It can be found in several places.
It's also on the American Backbone!
Gerard van Essen
FidoNet: 2:281/527
Contrast BBS, 31-70-3234903 (V34+, V32bis, V32Terbo, V.FC, HST 16k8). The
telephone number will change in june 1996, although the new number is not
known yet.
Internet: art@users.toolnet.org
Have fun.